Skip to content

Ruby: Support erb flow for ActionController #15555

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

hmac
Copy link
Contributor

@hmac hmac commented Feb 8, 2024

Use the same approach as with ViewComponent, to track flow into ERB template files via explicit render calls.

We don't yet deal with:

  • any options passed to render that change the template
  • implicit calls to render at return nodes of action methods

@github-actions github-actions bot added the Ruby label Feb 8, 2024
hmac added 2 commits March 6, 2024 11:41
Extend the existing modeling for ViewComponent to ActionController.

The `render` method in ActionController behaves in a similar way except
that the ERB file is evaluated in the context of the controller class,
rather than a separate view class. This means we need the value of
`self` at the `render` call to flow to the `self` in the ERB file.
@hmac hmac force-pushed the erb-steps-for-actioncontroller branch from 59386be to 16639bc Compare March 6, 2024 11:57
@hmac hmac force-pushed the erb-steps-for-actioncontroller branch from eac9716 to 4b31302 Compare March 6, 2024 15:24
or
input = "Argument[self]" and
output = "Argument[self].Parameter[self]" and
preservesValue = true
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we may need to synthesize a new set of render summaries, where we record the name of the ActionControllerActionMethod that calls it. Something like

private class ActionRenderMethod extends SummarizedCallable, LibraryCallableToIncludeInTypeTracking {
    private ActionControllerActionMethod m;

    RenderMethod() { this = "render view component " + m.getName() }

    override MethodCall getACallSimple() { result.getMethodName() = "render" and result.getEnclosingCallable() = m}

    override predicate propagatesFlow(string input, string output, boolean preservesValue) {
      // use a call-back summary, and adjust it to a method call below
      input = "Argument[self]" and
      output = "Argument[self].Parameter[self]" and
      preservesValue = true
  }
}

Then adjustedMethodCall needs to updated to include the name as well, and finally lookupMethodCall can be replaced with something that looks more like the existing Toplevel lookupMethod(ViewComponent::ComponentClass m, string name).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I realize that this may not work because of non-monotonicity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants